Don ’ t Say the ‘ P ’ Word By Lori Pajerek Lockheed Martin Federal Systems

August 2000 The problems linked to software development have retained their challenge since they were first documented by Frederick Brooks in the Mythical ManMonth [1]. Then as now, software-intensive development projects have been plagued by lack of predictability, schedule and cost growth, failure to meet requirements, and as a direct result of these, low customer satisfaction. We see numbers quoted that show how dismal the state of the art is; that the vast majority of software projects are failures [2]. We have searched for solutions to these problems, seemingly ever since the days of Ada Lovelace. There has been no lack of proposed solutions. Alan Davis chronicled a list of fads that have appeared on the software scene every few years since the 1970s [3]. Structured programming, object orientation, reuse, commercial off-the-shelf (COTS) products and others have had their day in the sun. Each has been heralded as a silver bullet, which none has been. This is not to say these ideas have no value; rather, that one must separate the substance from the hype. We incorporate what is valuable and make it standard practice. Each is recognized as one piece of the puzzle, not the whole solution. Progress is achieved slowly, small gains are made with each step. Because the problems remain largely unsolved, and because each of these doctrines is introduced with such fanfare, we are repeatedly seduced by the promise of a Holy Grail. Davis categorizes process maturity as one of these fads. When Sarah Sheard writes about the Frameworks Quagmire [4], she is reflecting some of the frustration of those attempting to comply with a confusing and sometimes conflicting set of process dictates. One look at her pictorial representation (see Figure 1) is enough to make us say that this has gone too far. The word ‘quagmire’ evokes the feeling by many that they are drowning in too much process. Other writers note that there is a growing body of opinion that the practices that the Software Engingeering Institute’s Capability Maturity Model (SEI CMM®) advocate are justified only for large and complex projects [5]. I can hear the debate now. Let’s listen: